Instant messaging (IM) service provides message exchanging procedures for client terminals. One standardization technique for IM related standards uses the Open Mobile Alliance (OMA). It should be understood that the present invention can be applied to messaging related to converged IP messaging or push-to-talk, and to other functions beyond messaging, such as media streams of continuous media types (including audio and video).
Instant Messaging (IM) refers to the transfer of messages between users in near real-time. Messages transmitted during the communication session can also be stored into a database of a network for later retrieval e.g. in situations in which the recipient is e.g. temporarily unavailable to receive the IM message.
IM conversations are messaging sessions between two or more users. A user can request to store messages of an incoming session or to start recording messages during an active conversation. A stored conversation may contain different amount of messages (from 2 to several hundreds) and each message can have text or multimedia content. This means that the size of the stored conversation may vary quite a lot. Therefore, it might not be appropriate to download the whole conversation, especially if the size is not known prior to the download.
The Session Initiation Protocol is specified by RFC 3261, titled “SIP: Session Initiation Protocol” (June 2002), which is incorporated herein by reference in its entirety. This document (RFC 3261) describes Session Initiation Protocol (SIP), an application-layer control (signaling) protocol for creating, modifying, and terminating sessions with one or more participants. These sessions include Internet telephone calls, multimedia distribution, and multimedia conferences. SIP invitations used to create sessions carry session descriptions that allow participants to agree on a set of compatible media types. SIP makes use of elements called proxy servers to help route requests to the user's current location, authenticate and authorize users for services, implement provider call-routing policies, and provide features to users. SIP also provides a registration function that allows users to upload their current locations for use by proxy servers. SIP runs on top of several different transport protocols. SIP can set up sessions between humans identified by e-mail-like identifiers or telephone numbers, but anything addressable by a host name or IP address can also participate in a SIP session. The process of session setup involves the discovery of a user wherever located so that a description of the session can be delivered to the user.
A radiophone-type “push-to-talk” call has been developed for cellular networks, to create a new service, distinct from voice call. This kind of arrangement is generally called a PoC network (push-to-talk over cellular network) which is a network deployed with a PoC server, and the PoC focus is on multiparty sessions with half duplex media exchange. OMA also specifies another release of PoC service, PoC Release 2.0. It contains PoC Box service similar to the IM Conversation history feature. Users can store PoC voice conversations into a PoC Box located in a network or in a terminal. Stored conversations can be retrieved later.
Converged Messaging (CPM) is an Open Mobile Alliance (OMA) work item. OMA CPM is a messaging framework which accommodates different user experiences such as deferred and instant messaging, session-based messaging, and half duplex/full duplex conferencing. It aims at consolidating common functionalities of existing messaging services and new features introduced by the convergence of communications brought by SIP-based technologies. It interacts with other OMA enablers such as Presence and XDM.
OMA Push To Talk over Cellular (PoC) is also an OMA work item. OMA PoC service is a two-way form of communications that allows users to engage in immediate communication with one or more users. PoC service is similar to a “walkie-talkie” application where a user presses a button to talk with an individual user or broadcast to a group of participants. The receiving participants hear the sender's voice either without any action on their part, for example, without having to answer the call or may be notified and has to accept the call before he can hear the sender's voice. Other participants can respond to this message once this initial speech is complete. The communication is half-duplex, that is to say, at most one person can talk at a time and all other participants hear the speech. This contrasts with voice calls, which are full duplex, where more than one person can talk at a time. The PoCv1.0 allows communication using voice only, the PoCv2.0 allows also video and text messaging.
The problem is as follows. The PoCv2.1 and CPMv1.0 enablers support usage of multiple media streams in sessions and usage of multiple User Equipments (UEs) by a single user. When the session is established, the user can accept the session invitation with all, subset or only one of his UEs. Each of the UEs can accept all or subset of the media streams offered in the session invitation. However the user may be after some time unhappy with the negotiated media streams presentation at the UEs and may wish to transfer some of the used media streams to another UE (e.g. video from mobile to TV set).
Session Description Protocol (SDP) is being used by a variety of distributed-over-the-network applications. These applications deal with multiple sessions being described by SDP and serving multiple users or services in the context of a single application instance. See RFC 4574 titled “The Session Description Protocol (SDP) Label Attribute” (August 2006) which is incorporated herein by reference in its entirety.
An SDP session description typically contains one or more media lines—they are commonly known as “m” lines. When a session description contains more than one “m” line, SDP does not provide any means to express a particular relationship between two or more of them. When an application receives an SDP session description with more than one “m” line, it is up to the application what to do with them. Grouping of media streams is allowed in SDP, according to RFC 3388 titled “Grouping of Media Lines in the Session Description Protocol (SDP)” (December 2002) which is incorporated herein by reference in its entirety.
There is currently no defined mechanism which would allow the user to transfer particular media stream(s) currently used at one of the user's UEs, out of arbitrary media streams of the same or different media type, to another of this user's UEs (where the first UE uses several media streams of the same media type), without requiring additional support in the latter UE beyond that described in RFC 3261.
Suppose that the UE1 was offered 8 media streams out of which the 1st, 2nd, 3rd, 4th, 5th, 7th and 8th media streams were accepted. This scenario can be described as follows. SDP offer fragment (some SDP lines are not listed):
m=audio 1000 ...(1st media stream)a=...m=video 1002 ...(2nd media stream)a=...m=message 20004 ...(3rd media stream)a=...m=audio 6000 ...(4th media stream)a=...m=video 12346 ...(5th media stream)a=...m=whatever1 4455 ...(6th media stream)a=...m=whatever2 6677 ...(7th media stream)a=...m=whatever 30004 ...(8th media stream)a=...SDP answer fragment (some SDP lines are not listed):
m=audio 8000 ...(1st media stream)a=...m=video 8002 ...(2nd media stream)a=...m=message 50004 ...(3rd media stream)a=...m=audio 5560 ...(4th media stream)m=video 8890 ...(5th media stream)m=whatever1 0 ...(6th media stream)m=whatever2 56677 ...(7th media stream)a=...m=message 50004 ...(8th media stream)a=...The user would like to offer 1st, 2nd and 7th media streams used by UE1 to UE2 and keep at the end only the 3rd, 4th, 5th, and 8th media stream at UE1.
It should be noted that a person of ordinary skill will also be familiar with RFC 3903 titled “Session Initiation Protocol (SIP) Extension for Event State Publication” (October 2004), which is incorporated herein by reference in its entirety. That document describes an extension to the Session Initiation Protocol (SIP) for publishing event state used within the SIP Events framework. The first application of this extension is for the publication of presence information. The mechanism described in RFC 3903 can be extended to support publication of any event state for which there exists an appropriate event package. It was not intended to be a general-purpose mechanism for transport of arbitrary data, as there are better-suited mechanisms for this purpose.
A person of ordinary skill will also be familiar with RFC 3265 titled “Session Initiation Protocol (SIP)-Specific Event Notification” (June 2002) which is also incorporated herein by reference in its entirety. That document describes an extension to the Session Initiation Protocol (SIP). The purpose of the extension is to provide an extensible framework by which SIP nodes can request notification from remote nodes indicating that certain events have occurred. Concrete uses of the mechanism described in this document may be standardized in the future. The event notification mechanisms defined in RFC 3265 were not intended to be a general-purpose infrastructure for all classes of event subscription and notification.
Additionally, a person of ordinary skill will be familiar with the memo titled “Referring to Multiple Resources in the Session Initiation Protocol (SIP)” dated Jun. 22, 2006 (draft-ietf-sipping-multiple-refer-06), which is incorporated by reference herein in its entirety. That document defines extensions to the SIP REFER method so that the method can be used to refer servers to multiple resources. Those extensions include the use of pointers to Uniform Resource Identifier.